Software Engineering(Software process)

Intro

Process：包含活动，限制和资源以产生一个想要输出的步骤

一个process包含一系列的tool和techniques

Software process：

特点：不是一个完全固定的过程，动态的调整更加有效
软件过程设计的基本的活动：

• Software specification
• Software design and implementation
• Software validation
• Software maintenance

软件生命周期：
Def：一个软件从定义、开发、使用和维护，直到最终被废弃，所经历的生存过程称为软件生存期或叫生命期。（最耗费的是维护）

Software process models

Def：软件过程的抽象表达

三个过程模型：

• The waterfall model(严格按照顺序执行)
• Evolutionary development（将规范、开发和验证活动穿插在一起，包含了很多次的循环）
• Component-based software engineering（基于大量可重用组件的存在，集成这些组件）

Reason： 形成共同的理解，寻找并评估达到过程目标的适当活动，为将被使用的特定情况调整一般过程

瀑布模型

过程：
特点：没有迭代从上到下，大多数软件开发都会迭代

缺点:

• 没有提供在开发过程中如何处理产品和活动变更的指导(假设需求可以被冻结)
• 将软件开发视为制造过程而不是创造过程
• 缺少迭代
• 最后的结果需要等很久

prototyoe（原型）

Def：原型是部分开发的产品

功能：

• 开发人员评估备选设计策略(设计原型)
• 用户了解系统将会是什么样子(用户界面原型)

优点：原型对于验证和确认是有用的
结合原型的开发： 快速原型法：

V model(瀑布模型的变化版本)

步骤：使用unit testing 去证明软件设计
，使用集成测试去验证结构设计，使用验收测试来验证需求，如果在验证和确认过程中发现问题，可以在重新执行右边的测试之前重新执行左边的步骤

与瀑布的不同：也是按步骤执行，但是后面的步骤建立了和前面的联系（可以验证需求和设计）

步骤：

Evolutionary development

Def:开发一个初始实现，将其公开给用户评论，并通过许多版本对其进行改进，直到开发出一个适当的系统

两个基本原型类型：勘探开发（Exploratory development）和Throwaway prototyping（抛弃原型）

优点：规格可以不断地开发，一个开发一个中小型系统的好的办法

步骤：

Incremental development

Def：和增量模型的区别：增量可以看做是软件的部分，可能是并行执行

优点：

• 客户不必等到整个系统交付后才能从中获得价值
• 客户可以使用早期的增量作为原型，并获得经验,告知他们以后的系统增量的需求
• 整体项目失败的风险较低
• 最重要的系统服务接受最多的测试是不可避免的

过程：有两次验证，增量搞完验证一次（方便定位），然后检查系统的时候再一次 和迭代开发的区别（两者都是阶段开发）：增量开发：从小型功能子系统开始，并在每个新版本中添加功能
迭代开发：从完整的系统开始，然后在每个新版本中更改每个子系统的功能

Spiral development（螺旋式开发）

Def：process用一个螺旋式的表示，每一个loop代表过程的一个阶段，每个loop有四个部分（目标设立，风险评估，开发和验证，计划）

特点：最大的特点就是引入了其它模型不具备的风险分析。在每一个迭代里，当确定了目标、方案和限制条件以后，进入风险评估阶段（识别并消除风险）。如果有不确定的风险，则需要进一步工作以将所有风险都确定。风险过大甚至会终止项目。当风险识别完成并有确定的风险消除方案以后，就继续采用瀑布模型完成一次迭代开发。

过程：

Component-based software engineering(CBSE)

Def：在组件对象模型的支持下，通过复用已有的构件，软件开发者可以“即插即用”地快速构造应用软件。


没有广泛应用：因为每个软件都是特殊的，很难遇到一个满足所有需求的部件

其他过程模型

Operational Specification Model

Transformational Model

这两个model依赖于形式化方法（形式化描述）（Formal Method）（如果能被计算机了解,能生成对应的东西）

对许多系统来说，需求的不确定性导致了后期开发的变化和问题。Zave提出了一种过程模型，它允许开发人员和客户在开发的早期检查需求及其隐含含义，在这个过程中，他们可以讨论和解决某些不确定性

Operational Specification

Def：在开发过程的早期执行(检查)需求并评估其含义

通过演示系统行为的方式来评估或执行系统需求。也就是说，一旦指定了需求，就可以用软件包进行演示。这样，在设计开始之前就可以评价它们的隐含含义。例如，如果规格说明要求计划构建的系统能够处理24个用户，规格说明的可执行形式就能够帮助分析人员确定用户数目是否给系统增加了太多的性能负担。

过程：

特点：可操作规格说明模型允许把功能和设计合并起来。图说明了可操作说明模型是如何运作的。注意，可操作规格说明模型与原型化模型类似，该过程允许用户和开发人员在早期检查需求。

Transformational Model

Def：可转换模型（transformational model）通过去除某些主要开发步骤来设法减少出错的机会。利用自动化手段的支持，转换过程使用一系列转换把需求规格说明变为一个可交付使用的系统

特点：更少的主要开发步骤，应用一系列转换将规范更改为可交付的系统，依赖于形式主义，需要正式的规范(以允许转换)

SoftWare Design and Implement

Software Design

软件设计：软件设计是对要实现的软件的结构、作为系统一部分的数据、系统组件之间的接口，有时还包括所使用的算法的描述

有设计过程：

Software implementation

特点：

• 顺理成章地从系统设计处理而来
• CASE工具可用于从设计生成框架程序，包括定义和实现接口的代码
• 编程是一项个人活动，没有通用的流程可循

CASE是什么：全称：Computer-Aided software engineering

• 包括设计编辑器、数据字典、编译器、调试器、系统构建工具等
• 可以使用CASE自动化的活动示例:
• 图形化系统模型的开发
• 使用数据字典理解设计
• 从用户创建的图形界面描述生成用户界面
• 通过提供有关正在执行的程序的信息来进行程序调试
• 自动将程序从旧版本的编程语言翻译成较新的版本

Software Validation

Verification 和 validation(检验和有效性验证)旨在表明系统符合其规范并满足系统客户的要求。

包括检查和评审过程和系统测试。

系统测试包括使用测试用例来执行系统，这些测试用例来源于系统要处理的真实数据的规范。

步骤：

test：
validation:生产的时候设定样例，然后下面再测试（有点类似Vmodel）

System evolution

Def：软件进化(软件维护)的成本可能比软件开发要高得多